home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1990 / Sep 90 / MacApp.Tech$ 9⁄14⁄90 / 1958-Shell Shocked in Lan-Sep90 < prev    next >
Encoding:
Text File  |  1991-03-06  |  3.0 KB  |  74 lines  |  [TEXT/GEOL]
  1. Item    1657317                         10-Sept-90        08:43PDT
  2.  
  3. From:   PASCOE1                         Pascoe, Geoff
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. Sub:    Shell Shocked in Lang. Wars
  8.  
  9. Phil,
  10.  
  11. "Let us pretend that we really are writing reusable modules."
  12.  
  13. "Pretend" is the operative word here.  And, yes all I care about is the
  14. interface.  Unfortunately, C++ DOES care about more than the interface.
  15.  
  16. Question:  Is private data and member functions part of an object's interface?
  17.  
  18. "Let's try that one again, too. If you _really_ have resuable code, then you
  19. could write a module in OP, link it into a C++ component, and invoke it from
  20. a Lisp program. Why do I need to know (or care) what language it was
  21. originally written in? Please note that this is not the way the world works,
  22. only the way it is supposed to work."
  23.  
  24. Yes, the world doesn't work that way.  Precisely my point!
  25.  
  26. "The whole point of "xxx.h" files is so that this does not happen.
  27. As long as the "xxx.h" file remains unchanged (which is really the
  28. public part of the interface) that can't happen."
  29.  
  30. Sadly, I don't share your faith in .h files.  Also, refer to the question
  31. above.
  32.  
  33. "Who can it be underwhelming and taking over the world?"
  34.  
  35. I can't answer a question I don't understand.
  36.  
  37. "Mene, mene, tekel uparshim."
  38.  
  39. Could you put that in English, please?
  40.  
  41. ---------------------------------
  42.  
  43. Peter,
  44.  
  45. Interestingly, there is/was an object-oriented language that had a feature that
  46. permitted programmers to insert classes in the class hierarchy.  Objective-C.
  47. The feature was called "pose-as", after the message (poseAs:) which could be
  48. sent to a class (classes are objects in Objective-C).  Some programmers found
  49. it very useful.  Unfortunately, it had some problems, particularly with
  50. multiple insertions.  I don't recall whether the problems were ones of
  51. implementation, design, or concept.  Nevertheless, I'm skeptical because of my
  52. previous experience.
  53.  
  54. Paramaterized types are real neat- at least for statically typed languages.
  55. They're very useful for data structure types of objects: lists, sets, bags,
  56. etc.  What are they?  Well, when you write a class that contains other objects
  57. you tell the class that the objects are a parameter, say TFoo.  You use TFoo
  58. throughout the class definition.  When you use the class for real objects
  59. (TRealObject) you declare the class with the type of the real object you will
  60. use it for.  Basically, say good-bye to type-coercions when using TList type
  61. containers.  Check out Meyer's book!
  62.  
  63. I agree with most of the rest of your statements.  I, personally, would not
  64. scream foul if I couldn't access instance variables directly.  As far as
  65. calling grandparent methods- big mistake.  This is like the goto of OOP.
  66. Although it might appear useful you'll be better off if you structure your
  67. classes so you don't have to do this.  I'm against a language feature that
  68. enables this.  NO INHERITED (-1) , ppppplease  (Roger Rabbit style).  Or, worse
  69. yet, the MANDATORY use of scope resolution operators to call inherited methods-
  70. another C++ "feature".
  71.  
  72. Geoff
  73.  
  74.